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SYSTEM AND METHOD FOR IMPLEMENTING A FLEXIBLE DATA-DRIVEN 

TARGET OBJECT MODEL 

BACKGROUND INFORMATION 

An integrated developinent environment ("IDE") is typically used to develop 
software in a "target" computer system. The IDE includes one or more "host" 
installations which may be connected to the target system in order to load the developed 
software into the target system and monitor its execution. A number of alternatives exist 
for connecting the target system to the host, but usually the connection is either an 
Ethernet or serial link. 

In a development system, the host is typically equipped with large amounts of 
RAM and disk space, backup media, printers, and other peripherals. In contrast, the 
target system typically has limited resources (small amounts of RAM, no disk, no 
display, etc.), and perhaps some small, amount of additional resources for testing and 
debugging. The target may include no more than a processor with on-chip RAM and a 
serial input/output channel The target's processor may be of various kinds including the 
PowerPC® processor manufactured by IBM Corp. or the Pentium® 11 manufactured by 
Intel Corp. The target may also include an operating system, such as VxWorks® from 
Wind River Systems, Inc., which may be used to control the allocation and usage of the 
target's resources. 

The IDE may include a number of "tools" that allow a software developer to 
easily develop software for the target system and monitor the generation of the developed 
software on the target system. One such tool may be an "object browser" which can be 
conveniently used to monitor the state of the target system while developed apphcations 
are executing. The object browser can be used to display information about "objects" in 
the system, for example, information about objects of the operating system executing on 
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the target. These objects may include tasks, semaphores, message-queues, memory- 
partitions, watchdogs, etc. Each object also has attributes which are the properties of the 
object. For example, a semaphore (an object) may have as attributes its name, 
identification number, and state (e.g., whether the semaphore is taken). The attributes of 
an object may be static (i.e., determining the object attribute does not require access to 
the target system) or dynamic (i.e., determining the object attribute does require access to 
the target system). The static attributes of the object may include, among others, a string 
describing the type of object (e.g., for the semaphore, the string may be "Semaphore"). 
The dynamic attributes may include, among others, the name of the object, the object's 
identification number, and the state of the object. 

In a host-target development environment, in order for tlie host to gather 
information about the objects running on the target, the host generally has one or more 
files describing the target system's implementation of the object and this description file 
is specific to the implementation of the object by the operating system running on the 
target system. For example, the description files can Hst offsets to internal fields within 
each object's data structure, allowing the tools on the host to locate information 
concerning the object running on the target system. Information concerning the object is 
then retrieved fi*om the target system using a standard communication protocol such as a 
Gopher program. The Gopher program describes a sequence of memory reads which 
results in a sequence of data to be returned to the calling host. 

This scheme just described for gathering information is unwieldy in practice and 
not easily scalable. It is expensive to extend and maintain because introducing a new 
object requires updating many architecture specific files. 

SUMMARY OF THE INVENTION 

A method and system for retrieving and presenting data fi-om a target system, the 



wo 01/52055 



3 



PCT/USOl/00237 



method includes retrieving object data from the target system for an object selected by a 
client, the retrieval performed by using one of the data retrieval programs corresponding 
to the target system. The method also includes providing the object data and a 
• presentation format to the client, the object data and the presentation format are based 
upon one of the object description files corresponding to the object selected by the client. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows a block diagram illustrating a development environment according to a first 
exemplary embodiment of the present invention. 

Figs. 2a-b show a flowchart illustrating the steps involved in gathering object information 
according to the first exemplary embodiment of the present invention. 

Fig. 3 shows a user interface according to a second exemplary embodiment of the present 
invention. 

Figs. 4a-h show sample extensible Markup Language ("XML") code for implementing a 
semaphore object according to the second exemplary embodiment of the present 
invention. 

Fig. 5 shows a block diagram illustrating the development environment according to a 
third exemplary embodiment of the present invention. 

Figs. 6a-b show a flowchart illustrating the steps involved in gathering object information 
according to the third exemplary embodiment of the present invention. 
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Fig. 7 shows a block diagram of the development enviromnent according to a fourth 
embodiment of the present invention. 

Fig. 8 shows a flowchart illustrating the steps involved in gathering object information 
5 according to the fourth embodiment of the present invention. 

Figs. 9a-b show sample XML code for implementing a semaphore object according to the 
fourth embodiment of the present invention. 

10 DETAILED DESCRIPTION 

According to the present invention, a flexible object model may be implemented, 
for example, in the IDE employing host and target systems. The flexible object model 
allows information about objects running on the target to be gathered independently of a 
15 target's architecture (i.e., the operating system running on the target and the processor 

architecture of the target). The flexible object model has the following benefits: 

(1) It supports an object framework usable by more than one development tool (i.e., can 
be used by any number of apphcations such as the browser, debugger, shell, etc.); 

(2) It presents an interface to a client (e.g., the object browser) that is independent of the 
20 target's operating system and processor architecture; 

(3) It allows browsing of public attributes of objects while hiding object implementation 
details; 

(4) It is self-descriptive regarding those objects that are supported for each given 
operating system, and this is user extensible by augmenting the existing (XML) 

25 database with descriptions of new objects; 

(5) It provides information regarding how object data may be most naturally presented 
and manipulated by the client; and 
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(6) It provides information about what actions on objects are permissible. 

In one exemplary embodiment of the present invention, extensible Markup 

Language ("XML") is used to describe the publicly accessible information of an object as 

well as the method by which that information can be accessed from the object and used in 

the IDE. XML is referred to as a "metalanguage", or a language for describing other 

languages. An XML file is made up of XML elements, each of which consists of a start 

tag (e.g., <title>), an end tag (e.g., </title>), and the information between the two tags 

(referred to as the content). Like Hypertext Markup Language ("HTML"), an XML 

document holds text annotated by tags. However, unlike HTML, XML allows an 

unlimited set of tags, each indicating not how something should look, but what something 

means. Rather than describing the order and fashion in which the data should be 

displayed, the tags in XML indicate what each item of data means. Detailed information 

on the XML standard is provided in: "Extensible Markup Language (XML) 1.0", W3C 

Recommendation lO-February-1998, REC-xml- 199802 1.0, http://www.w3. orgATMlEC- 
xml, 

XML allows the host to carry architecture-generic descriptions of objects, each 
object having an XML file. This architecture-generic description would define the object 
data to be returned from the target and also define its presentation to the client. XML is 
thus suited for implementing the exemplary embodiment because it allows for 
architecture-generic descriptions of how to access and use data pertaining to objects. 

The use of -XML as the object description language would have the following 
benefits: 

(1) provides a machine readable object description; 

(2) it is an open standard which will allow the use of third party tools to browse, format, 
and manipulate the data contained in the XML database; 

(3) potential for users to use a tool to define their own objects; and 

(4) compilers to produce source-code, documentation, and browsing support. 
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Referring to the figures in which Hke numerals indicate hke elements. Fig. 1 is a 
block diagram illustrating an exemplary development environment 1 according to a first 
exemplary embodiment of the present invention. As shown, a host 1 0 is connected to a 
target 20 via, for example, a serial or Ethernet link. 

The host 1 0 may comprise a computing environment having various well-known 
components and systems (for example, a processor, a memory system, a display, and user 
input devices such as a keyboard and mouse.). The host 10 may include an operating 
system (e.g., Umx, Windows, Linux, etc.) which controls the execution of applications on 
the host 10. 

The target 20 may comprise a second computing environment which, for 
exainple, is intended to opeiaLe apart from the host 10. The processor of the target 20, for 
example, may be an Intel Pentium® D processor or an IBM PowerPC® processor. The 
target 20 may include fewer resources than the host 10, thus making it advantageous to 
perform software development on the host 1 0 prior to implementation in the target 20. 
The target 20 may include an operating system 150 which controls the execution of 
applications and other objects running on the target 20. The operating system 150, along 
with user applications running on the target 20, uses various kernel objects ("objects") 
such as semaphores and tasks. 

The host 1 0 includes a development system 1 5 to be used in developing software 
for the target 20. Included in the development system 15 is at least one client 105, which 
may be one of a number of known development tools (e.g., the object browser, debugger, 
etc.). During operation, the client 105 may require information about objects running on 
the target 20. In order to monitor the operations of objects on the target 20, an 
application programming interface ("API") 110 is provided giving the client 105 access 
to an object interface ("01") 1 15 and which allows the client 105 to access information 
(e.g., attributes) about the objects running on the target 20. The API 1 10 thus allows 
development tools such as the object browser, debugger, command line shell, etc. to 
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communicate with the 01 1 15. 

The 01 1 15 is a program that allows the client 105 to obtain information about 
objects running on the target 20 independently of the target's architecture (which is 
described below) or its operating system. The Oil 15 also includes an XML interpreter 
which is used to read XML files and provide access to their content and structure. 

The development system 15 also includes a target interface ("Tr*) 120 which is 
used by the 01 1 15 to access information about the objects running on the target 20. The 
TI 120 includes the Gopher standard protocol which is used to gather information about 
an object running on the target 20. 

The development system 15 further includes an object database containmg 
descnptions of objects for each known operating system and also data retrieval programs 
for various target processor architectures. In the first exemplary embodiment, the object 
database is an XML object database 130 and the object descriptions for each known 
operating system are implemented using. XML. Also, in the first exemplary embodiment, 
Gopher programs, corresponding to recognized target processor architectures, are the data 
retrieval programs. However, in other embodiments, the object descriptions may be 
implemented using other languages and other programs may be used to retrieve data from 
the target 20. The XML object database 130 may be accessed by the Oil 15 in order to 
process requests by the chent 105 for information about an object running on the target 
20. 

Figs. 2a-b (hereinafter, collectively referred to as "Fig. 2") show a flowchart 
illustrating the steps involved in gathering information about the objects running on the 
target 20 using the first exemplary embodiment of the present invention. In step 203, the 
chent 105 is launched by, for example, a user. In step 206, the client 105 instantiates the 
01 1 1 5 in order to get object information from the target 20. The OI 1 1 5 needs to be 
initialized. In step 209, the 01 1 15 queries the target 20 via the TI 120 for information 
regarding the processor type and the operating system 150 of the target 20 and retrieves 
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this information from the target 20. In step 215, the 01 1 15 loads the XML object 
description files for the specified target operating system from the XML object database 
130. After the XML object description files are loaded and successfully validated against 
a Document Type Definition ("DTD") file, the 01 1 15 is now initialized. 

In step 221, the client 105 "enumerates" all the objects supported by the Oil 15. 
Enumerating the objects means to determine all the static attributes of the known objects, 
i.e., those attributes which do not require access to the target 20. The client 105 is 
provided enumeration information (i.e., information about the static attributes of the 
object) by the 01 1 15. The 01 115 obtains the enumeration information solely by using 
the XML object descriptions in the XML object database 130: there is one XML object 
^escnpuion per Ouject supported. No reference is made to the target 20 via the TI 120 for 
enumeration of the supported objects. The attributes of each object are defined in the 
XML object database 130 and may include, among others, the name of the object, the 
standard icon, the state, label, whether the object is displayable, how data displayed, etc. 

In step 227, the client 105 requests fiirther details about an object selected by the 
user. In step 230, the client 105 sends a reference to the object selected to the OI 1 15 via 
the API 1 10. In step 233, the 01 1 15 accesses the XML object database 130 to retrieve 
the XML object description corresponding to the selected object. The OI 1 15 also 
retrieves from the XML object database 130 the Gopher program corresponding to the 
processor of the target 20, A Gopher program may exist for each of the many possible 
target processor architectures if such a program is required - an advantage of this 
embodiment of the present invention is that a Gopher program can be shared by different 
target processor architectures if they use the same memory layout for software objects. 

In step 239, the 01 1 15 accesses the target 20 using a data retrieval method to 
collect data from the target 20. In one embodiment, the data retrieval method is passing 
the Gopher program from the 01 1 15 through the TI 120 to the target 20 in order for the 
01 1 1 5 to gather data about the selected object. The returned data is referred to as a 
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"Gopher tape." In step 242, the 01 1 15 decodes the data returned from the target 20 
based on the XML object description retrieved from the XML object database l30. In 
step 245, the OI 115 sends the decoded data to the client 105 along with a presentation 
format. The presentation format is also based on the XML object description and 
instructs the client 105 on how to display the decoded data. The decoded data and the 
presentation format allow the client 1 05 to be data driven. The decoded data for the 
selected object is returned to the client 105 as a set of object attributes. In step 248, the 
client 105 uses the set of object attributes which was returned as a resuh of the original 
request. Such use of the object attributes can be, for example, in the case of the object 
browser, to display the object's attributes in a format suitable for a graphical user 



The previous embodiment shows how the Oil 15 can be used to retrieve 
information about objects running on the target. In a second exemplary embodiment 
according to the present invention, the 01 1 15 can be used by a specific development tool 
- an object browser - to display information about objects running on a specific target. In 
this example, the processor of the target 20 is the PowerPC® processor, and the operating 
system 1 50 of the target 20 is Vx Works®. In other alternative embodiments, the 01 1 15 
may be used by other development tools such as a debugger (e.g., the debugger would 
need to enumerate tasks in order to attach to one of them), and a command line shell 
(e.g., the shell may provide system information such as a snapshot of the tasks running on 
the target). 

The following example illustrates the use of the exemplary 01 1 15 and the XML 
object database 130 by the object browser to obtain information (i.e., attributes) about 
objects running on the target. Referring again to Fig. 2 but now for the case where the 
client 105 is specifically the object browser, in step 203, the object browser is launched 
by, for example, the user. In step 206, the object browser instantiates the 01 1 15 in order 
to get object information from the target 20. In step 209, the OI 1 15 queries, the target 20 
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via the TI 120 for information regarding the processor type and the operating system 150 
of the target 20 and retrieves this information from the target 20. 

In step 215, the 01 1 15 loads the XML object descriptions for Vx Works® from 
the XML object database 130. In step 221, the object browser enumerates all object 
types supported by the 01 1 15 using the XML object descriptions obtained from the 
XML object database 130. In step 227, the object browser requests fiirther details on a 
particular object selected by the user of the object browser. In step 230, the object 
browser sends the object selected to the 01 1 15 via the API 110. 

In step 233, the OI 1 15, based on the object selected, retrieves the corresponding 
XML object description from the XML object database 130. The 01 115 also retrieves 
from the XbAL object database 130 tlic Gopher program corresponding to the PowerPC® 
processor in order to retrieve the attributes of the selected object running on the target 20. 
In step 239, the 01 1 15 accesses the target 20 to retrieve the attributes of the selected 
object running on the target 20 using the Gopher program by sending the Gopher 
program through the TI 120 to the target 20. 

In step 242, the OI 1 15 decodes the data retumed from the target 20 based on the 
XML object description retrieved from the XML object database 130. In step 245, the OI 
115 sends the decoded data (i.e., object attributes) to the object browser along with the 
presentation format. In step 248, the object browser displays the object attributes in the 
format as specified by the presentation format. 

Fig. 3 shows a user interface of the object browser according to the second 
exemplary embodiment of the present invention. In Fig. 3, all of the objects types 
supported are shown. The object types supported here are: (1) protection domains, (2) 
memory partitions, (3) tasks, (4) semaphores, (5) message queues, (6) watchdogs, (7) 
page managers, (8) page pools, (9) virtual memory contexts, (10) file descriptors, and 
(1 1) modules. In Fig. 3, a task browser is selected, allowing the user to see detailed 
information about a particular task. The task list shown (tMgrTask, tExcTask, etc.) in 
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Fig. 3 is retrieved from the target 20. The user can expose further levels of detail by 
clicking the "plus sign" icon. In Fig. 3, specific object attributes of tWdbTask are shown 
such as its ID, Name, Owner, Status, etc. 

Figs. 4a-h (hereinafter, collectively referred to as *Tig. 4") show sample XML 
code for implementing a semaphore object according to the second exemplary 
embodiment. The first line of Fig. 4 is an XML declaration which specifies the version 
of XML being used (here, version "1 .0" is used). The first line also contains an encoding 
declaration (here, characters are encoded using UTF-8). The second line references the 
external DTD file. This file essentially defines the rules of the document, such as which 
elements are present and the structural relationships between the elements. In line two, 
the "obJTypes.dtd'' is defined as the DTD. With XML, DTDs are optional. 

The third and fourth lines of Fig. 4 define the specifics of the object type. For 
example, the object is defined as a semaphore (objTypeName = "sem") and given a 
unique object number (objTypeNumber = "1"). 

The "objTypeAttributes" in Fig. 4 contain descriptions of those attributes which 
are static, i.e., those attributes which do not require target access. The "objAttributes" 
contain descriptions of those attributes which do require target access. The "objGopher" 
contains the Gopher programs used by the 01 11 5 for each target architecture along with 
a logical identifier to be attached to the returned value. This identifier is referenced in the 
"objAttribute" to decode the returned data. 

Fig. 5 is a block diagram illustrating a third exemplary embodiment according to 
the present invention where a user-defined XML object database 135 is added to the 
development system 15. The user-defined XML object database 135 may contain user- 
defined object descriptions, hi one embodiment, the user-defined object descriptions are 
in XML in order for the object descriptions to be architecture-generic. The user-defined 
XML object database 135 provides for the extension of known objects by adding to the 
database a user-defined XML object description which describes the new object. The 
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user-defined XML object database 135 allows the user to add custom objects and thus 
expand the number of objects supported by the 01 115. 

Figs. 6a-b (hereinafter, collectively referred to as "Fig. 6") show a flowchart 
illustrating the steps involved in gathering information about the objects running on the 
target 20 using the third exemplary embodiment of the present invention. In this 
exemplary embodiment, step 218 is added to the steps described earlier in Fig. 2 for 
gathering information about an object running on the target 20. 

Referring to Fig. 6, in step 218, the OI 1 15 loads the user-defined XML object 
descriptions (the plug-ins) fi*om the user-defined XML object database 135 for the 
specified target operating system. The plug-ins allow the user to add custom objects. 
The plug-ms also allow the 01 1 15 to support user defined custom objects. The plug-ins 
expand the number of objects that are supported by the 01 1 15. After the plug-ins are 
loaded in step 2 1 8, the 01 1 1 5 is now inifiahzed. 

In a fourth embodiment of the present invention, data extraction routines are used 
rather than the Gopher program to retrieve object data fi-om the target 20. Fig. 7 is a 
block diagram illustrating the development environment 1 according to the fourth 
embodiment of the present invention. 

Included in a data extraction development system 25 is an object description 
module 155 which contains descriptions of each of the objects running on the target 20. 
In order for the object descriptions to be architecture-generic, they are implemented using 
XML. The object description module 155 contains XML code for describing each of the 
object's public attributes. The object description module 155 also contains data 
extraction routines; each object description specifies a data extraction routine for that 
object. Different data extraction routines may exist for each target processor architecture 
supported by the data extraction development system 25 and the data extraction routines 
may be pre-compiled using the appropriate compiler. 

The data extraction routine is downloaded to the: target 20 via the TI 120 in order- - 
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to assemble data about the selected object on the target 20 in the format described in the 
XML object description found in the object description module 155. In an alternative 
embodiment, the data extraction routine aheady resides on target 120 and therefore does 
not need to be downloaded. The data extraction routine assembles the data about the 
selected object on the target 20 into a data packet and places it in a target buffer. 

Figure 8 is a flowchart illustratmg the steps involved in gathering object 
information in the fourth embodiment of the present invention. In step 505, the client 
105 is launched by, for example, a user. In step 510, the Oil 15 queries the target 20 via 
the TI 120 for information regarding the processor type and the operating system 150 of 
the target 20. In step 5 1 2, the 01 1 1 5 loads the XML files for the specified target 
operatmg system from the object description module 155. In step 514, the client 105 
"enumerates" (determines) all the object types supported by the 01 1 15. 

In step 515, the chent 105 selects an object for which to obtain information and 
this selection is sent to the QI 1 15 via the API 110. In the case of the object browser, the 
object whose public attributes are to be displayed is selected by a user. In step 520, the 
object description for the selected object is fetched from the object description module 
155. In step 525, the data extraction routine corresponding to the processor architecture 
of the target 20 is fetched from the object description module 155. 

In step 535, the compiled data extraction routine is sent to the target 20 via the TI 
120. In step 540, the data extraction routine assembles the requested data for the selected 
object and places this data into a data packet and puts this data packet into a target buffer. 
In step 550, the 01 1 15 uses the object description, found earlier in the object description 
module 155, in order to interpret the retrieved data. The 01 1 15 formats the requested 
data by matching it with the object description found in the object description module 
155. In step 555, the 01 115 sends the decoded data to the client 105. In the case that the 
client 105 is the object browser, the decoded data (the object information) can be 
displayed to the user. 
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Figs. 9a-b (hereinafter, collectively referred to as 'Tig. 9") show a sample listing 
of XML code used to implement a semaphore object according to the fourth embodiment 
of the present invention. The first line of Fig. 9 is an XML declaration which specifies 
the version of XML being used (here, version "LO" is being used). The first line also 
contains an encoding declaration (here, characters are encoded using UTF-8). The 
second line specifies the name of the object; in Fig. 9, the object is named 
"binarySemaphore". A <requestBegin> element defines the routine (i.e., the data 
extraction routine) needed to request object data to be collected. A <requestEnd> 
element defines the routine needed to complete the object data request. 

A <data> element defines the data assembled for use by the object browser. The 
<uata> element includes the definition of the data items which will be assembled by the 
target 20 and downloaded to the host 10 in a data packet. The host 10 uses <dataltem> 
definitions in the <data> element to decode this data packet. For each <dataltem>, 
information is provided to allow the host 1 0 to extract the data firom the data packet and. 
to know how to display it in the object browser. A "type" attribute specifies the number 
of bytes in the data item and how it should be interpreted. A "idref attribute is an 
intemal name for the dataltem. A "text" attribute is the label to be used in the object 
browser for the dataltem, A "format" attribute is a C-style format stating how the data 
should be displayed by the client. A "display" attribute indicates whether the dataltem is 
displayed; if display is set to "always" then the dataltem is always displayed, if display is 
set to "optional" then the user can elect to display the dataltem, and if display is set to 
"never" then the dataltem is never displayed. 

In the preceding specification, the invention has been described with reference to 
specific exemplary embodiments thereof It will, however, be evident that various 
modifications and changes may be made thereunto without departing fi-om the broader 
spirit and scope of the invention as set forth in the claims that follow. The specification 
and drawings are accordingly to be regarded in an illustrative rather than restrictive sense. 
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WHAT IS CLAIMED IS: 

1 . A method for retrieving and presenting data from a target system, comprising: 

receiving target system information from the target system; 

retrieving a set of object description files corresponding to the target system 
information; 

sending to a client a set of objects supported based on the set of object description 
files retrieved; 

receiving a selected object from the client; 

selecting one of the set of object description files corresponding to the selected 

object; 

retrieving one of a set of data retrieval programs corresponding to the target 

system information- 
retrieving object data about the selected object using the retrieved one of the set of 

data retrieval programs; 

decoding the object data about the user selected object using the selected one of 

the set of object description files corresponding to the selected object to form decoded 

object data; and 

sending the decoded object data and a presentation format to the client allowing 
the client to be data driven. 

2. The method of claim 1 wherein the target system information includes a processor 
type of the target system and an operating system type of the target system. 



3. 



The method of claim 2 wherein the set of object description files is a set of XML 
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object description files and the set of data retrieval programs is a set of Gopher programs. 

4. The method of claim 3 wherein retrieving the set of object description files 
corresponding to the target system information includes retrieving the set of XML object 
description files corresponding to the operating system type of the target system. 

5. The method of claim 4 wherein retrieving the set of object description files 
corresponding to the target system information includes retrievmg a set of user-defined 
XML object description files corresponding to the operating system type of the target 

C\/ct/=>-m 

6. The method of claim 1 wherein the selected object is received from the chent 
using an application programming interface. 



7. The method of claim 5 wherein retrieving one of the set of data retrieval programs 
corresponding to the target system information includes retrieving one of the set of 
Gopher programs corresponding to the processor type of the target system. 

8. The method of claim 7 wherein retrieving the object data about the selected object 
includes passing the retrieved one of the set of Gopher programs through a target 
interface to retrieve the object data for the selected object from the target system. 



The method of claim 1 wherein the client is an object browser. 
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1 0. The method of claim 3 wherein the set of XML object description files is stored in 
an XML object database and the set of Gopher programs is stored in the XML object 
database. 

1 1 . The method of claim 2 wherein the set of object description files is a set of XML 
object description files and the set of data retrieval programs is a set of data extraction 
routines. 

\i. i ne metnou Oi cianri 1 1 wnerem accessmg xne object database to retneve one of a 
set of data retrieval programs corresponding to the target system information includes 
accessing the object description module to retrieve one of the set of data extraction 
routines corresponding to the processor type of the target system. 

13. The method of claim 12 wherein retrieving the object data about the selected 
object includes passing the retrieved one of the set of data extraction routines through a 
target interface to retrieve the object data for the selected object fi-om the target system. 

14. The method of claun 13 wherein the set of XML object description files is stored 
in an object description module and the set of data retrieval programs is stored in the 
object description module. 
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15. A development system, comprising: 
a client; 

an object database including a set of object description files and a set of data 
retrieval programs, the set of object description files including at least one object 
description file corresponding to an object selected by the client, the set of data retrieval 
programs including at least one data retrieval program corresponding to the target system; 

an object interface coupled to the client and the object database to retrieve object 
data fi-om an object in the target system using the at least one data retrieval program 
corresponding to the target system, and providing the object data to the client based on 
the at least one object description file corresponding to the object selected by the client; 
and 

'a target interface coupled to the object interface to enable coimection of the object 
interface to the target system. 

16. The development system of claim 15 wherein the object interface obtains target 
system information fi-om the target system, the target system information including a 
processor type of the target system and an operating system type of the target system. 

17. The development system of claim 15 wherein the coupling between the cHent and 
the object interface includes an application programming interface. 



18. The development system of claim 15 wherein the client is an object browser. 
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19. The development system of claim 15 wherein the object database is an XML 
object database and the set of object description files are a set of XML object description 
files and the set of data retrieval programs are a set of Gopher programs. 

20. The development system of claim 19 further comprising a user-defined XML 
object database coupled to the object interface and including a set of user-defined XML 
object description files corresponding to a set of user-defined objects. 

21 . The development system of claim 20 wherein the object interface retrieves the set 
of XML object description files corresponding to the operating system type of the target 
system and the set of user-defined XML object description files corresponding to the 
operating system type of the target system. 

22. The development system of claim 21 wherein the client enumerates a set of 
objects supported using the set of XML object description files and the set of user- 
defined XML object description files. 

23. The development system of claim 22 wherein the object interface receives the 
object selected by the client. 

24. The development system of claim 23 wherein the object interface retrieves a 
particular one of the set of XML object description files corresponding to the object 
selected by the client and retrieves a particular one of the set of Gopher programs 
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corresponding to the processor type of the target system. 



25. The development system of claim 24 wherein the object interface retrieves the 
object data from the object in the target system by sending the retrieved one of the set of 
Gopher programs through the target interface into the target system. 



26. The development system of claim 25 wherein the object data is decoded using the 
retrieved one of the set of XML object description files to form decoded object data. 



27. The devclopiuciit system of claim 26 wherein the decoded object data and a 
presentation format is sent to the client allowing the client to be data driven. 



28. The development system of claim 16 wherein the object database is an object 
description module and the set of object description files in the object database are a set 
of XML object description files and the set of data retrieval programs in the object 
database are a set of data extraction routines. 



29. The development system of claim 28 wherein the object interface retrieves a 
particular one of the set of data extraction routines corresponding to the processor type of 
the target system. 



30, The development system of claim 29 wherein the object interface retrieves the 
object data from the object in the target system by passing the retrieved one of the set of 
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data extraction routines through the target mterface into the target system. 



31. A method for retrieving and presenting data from a target system, comprising: 



retrieving object data from the target system for an object selected by a client, the 
retrieval performed by using one of the set of data retrieval programs corresponding to 
the target system; and 

providing the object data and a presentation format to the client, the object data 
and the presentation format based upon one of a set of object description files 
corresponding to the object selected by the chent. 



32. The method of claim 3 1 wherein retrieving the object data includes receiving 
target system information from the target system. 



33. The method of claim 32 wherein retrieving the object data includes retrieving a 
set of object description files corresponding to the target system information. 



34. The method of claim 33 wherein retrieving the object data includes sending to the 
client a set of objects supported, the set of objects supported based on the set of object 
description files retrieved. 
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35. A device comprising: 
a medium; and 

a set of instructions recorded on the medium; 

wherein the set of instructions, when executed by a processor, cause the processor 
to: 

receive target system information from the target system; 

retrieve a set of object description files corresponding to the target system 
information; 

send to a client a set of objects supported based on the set of object description 
receive a selected object from the client; 

select one of the set of object description files corresponding to the selected 

object; 

retrieve one of a set of data retrieval programs corresponding to the target system 
information; 

retrieve object data about the selected object using the retrieved one of the set of 
data retrieval programs; 

decode the object data about the user selected object using the selected one of the 
set of object description files corresponding to the selected object to form decoded object 
data; and 

send the decoded object data and a presentation format to the client allowing the 
client to be data driven. 
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Fig. 2a 
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Fig. 2b 
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Fig. 4a 



<?xnil version="1.0" encodmg=^"UTF-8"?> 
<!DOCTYPE objType SYSTEM "objTypes.dtd"> 

<objType objTypeNumber="r' objTypeName="sem" objTypeHandler="tom" 
symboITableName="seinCIassId"> 
<objTypeAttributes> 

<objTypeAttribute key="objTypeVisiblityLevel"> 
<value type="Integer"> 

<literal>l</literal> 

</value> 
<fonnatStr> 

<literal>%d</literal> 
<yformatStr> 
</objTypeAttTibute> 

<objTypeAttribute key='*objTypeStringl"> 
<valueStr> 

<literal>Semaphore<Aiteral> 
<y'valueStr> 
</objTypeAttribute> 

<objTypeAttribute key="objTypeStrmg2"> 
<valueStr> 

<IiteraI>Semaphores</literal> 
</valueStr> 
</objTypeAttribute> 

<objTypeAttribute key=*'objTypeIconLarge"> 
<vaIueStr> 

<literal>semL.ico</literaI> 
<valueStr> 

</objTypeAttribute> 

<objTypeAttribute key="objTypeIconSmair'> 
<vaIueStr> 

<literal>sem.gif</literal> 
</valueStr> 

</objTypeAttribute> 
<yobjTypeAttributes> 
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Fig. 4b 

<objAttributes> 

<objAttribute k:ey="objId"> 
<Iabel> 

<literal>ID</literal> 

</label> 
<value> 

<substitute fieldName-"objId"/> 

</value> 
<formatStr> 

<literal>%08x<yiiteral> 
</fonnatSti> 
<detailLevel> 

<literal>l<;/literal> 
</detailLevel> 
</objAttribute> 

<objAttribute key="objName"> 
<label> 

<literal>Name</literal> 

</label> 
<value> 

<substitute fieldName^"objName'V> 

</value> 
<fonnatStr> 

<literal>%s</literal> 
</formatStr> 

<detailLeveI> 

<literal>l</literal> 
</detailLevel> 
</objAttribute> 

<objAttribute key="objOwner"> 
<label> 

<Iiteral>Owner</literal> 

</labeI> 
<value> 

<substitute fieldNaine="obj Owner' V> 

<yvalue> 
<forTnatStr> 

<literal>0x%08x<vaiteral> 
^formatStr> 

<detailLevel> 

<literal>l</literal> 
</detailLeve]> 
</objAttribute> 
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Fig. 4c 

<objAttribute key="objHasChildren"> 
<value> 

<switch fieldName="objChildListPtT"> 
<case caseValue="0"> 

<literal>false</literal> 

<case> 

<case caseValue="*"> 

<Iiteral>true</literal> 

</CQSt> 

</switch> 

</value> 
<fonnatStr> 

<literal>%s</literal> 

</formatStr> 
</objAttribute> 
<objAttribute key="objType"> 

<label> 

<^abel> 
<value> 

<substitute fie]dName=="seniType"/^ 

</value> 
<fonnatStr> 

<literal>Ox%x</literal> 
</formatStr> 
<valueStr> 

<s witch fieldNaine="semType"> 
<case caseValue="0"> 

<Iiteral>Binary</literal> 

</case> 

<case caseValue=" 1 "> 

<Uteral>Mutex</literal> 

</case> 

<case caseValue=*'2"> 

<literal>Countmg</literal> 

</case> 

<case caseValue="*"> 

<literal>UNKNOWN</literal> 

</case> 
</switch> 
</valueStr> 
<detaiILeveI> 

<literal>l</literal> 
</detailLevel> 
</objAttribute> 



wo 01/52055 PCX/ II SO 1/00237 

8/19 



Fig> 4d 



<objAttribute key=*'objState"> 

<! -There are two label entries here. The first will be overridden by the second, 
if the second does not return a null value when processed, i.e. if the fleldMap contains an entry for the 
"semType" fieldName, the second label will override the first when processed. In the case of a 
getDatabaseAttributesO call, the second will return a null since "semType" will not be in the field map, and 
the value contained in the first will persist.--> 

<label> 

<literal>State/Count/Owner</literai> 

</label> 
<label> 

<switcb fieldName="semType"> 
<case caseValue="0"> 

< [--Binary Seniaphore-> 
<Iiteral>State</literal> 

</case> 

<case case Value- ' 1 "> 

<!-Mutex Semaphore-> 

</case> 

<case caseValue="2"> 

<!— Counting Semaphore~> 
<literal>Count</literal> 

</case> 

<case caseValue=="*"> 

<literal>OvvTier</literal> 

</case> 
</switch> 

</label> 
<value> 

<substitute fieldName="semState"/> 

</value> 
<formatStr> 

<s witch fieldName="semType"> 
<case caseValue=*'2"> 

<! -Counting Semaphore - display as decimal~> 
<literal>%d</literal> 

</case> 

<case caseValue="*"> 

<!— Any other sort of semaphore - display as hex~> 
<literal>Ox%x</literal> 

</case> 
</switch> 
</formatStr> 
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Fig, 4e 

<valueStr> 

<! -Override the valueStr, even though the value and formatStr has 
been specified. This allows decoding of the Semaphore static into plain text The only option is for a 
Counting, or unknown Semaphore, where no CaseValue is specified. This allows the XML code to fall 
through the Switch statement without finding a match. In this case, no value will be inserted into the 
valueStr from here, leaving the XML code to compose one from the contents of the value combined with 
the fonnatStr.-> 

<switch fieldName="semType"> 
<case caseValue="0"> 

<!-Binary Semaphore— > 
<switch fieldName-"semState"> 
<case caseValue="0"> 

<literal>FULL</literal> 

</case> 

<case caseValue="*"> 

<Iiteral>EMPTY</literal> 

</case> 

</case> 

<case caseValuc=" r*> 

<!-Mutex Semaphore— > 
<switch fieldName="semState"> 
<case caseValue="0"> 

<literal>UnowTied<yiiteraI> 

</case> 
</switch> 

</case> 

<!~For caseValue = 2 (Counting semaphore) or for any 
other value, let this fall through without filling in a value. In this case, a valueStr will be composed 
automatically from the value and formatStr entries— > 

<Jsmtch> 
</valueStr> 
<detailLevel> 

<literal>l<;/literal> 
</detailLevel> 
<;/objAttribute> 

<objAttribute key="objOptions"> 
<label> 

<literal>Options</literal> 

</labeI> 
' <value> 

<substitute fieldName=="semOptions"/> 

</value> 
<formatStr> 

<literal>0x%08x</literal> 
</formatStr> 
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Fig. 4f 

<vaIueStr> 

<typedef> 

<switch fieldName="semOptions" f3eldMask="0x0O03'*> 
<case caseVaJue='*0"> 

<literal>SEM_Q_FIFO</literal> 

</case> 

<case caseValue="r'> 

<literal>SEM_Q_PRIORITY</literal> 

</case> 

<case caseValue="*"> 

<literal>SEM_Q_UNKNOWN</literal> 

</case> 
<^switch> 

<bitfield fieldNaine=*'semOptions" 

fieldMask="OxFFFFFFFC"> 
<bit mask="0x0004"> 

<literal>SEM_DELETE_SAFE<;/Iitexal> 

</bit> 

<bit mask="0x0008'> 

<literal>SEM„INVERSION_SAFE</literal> 

</bit> 

<bit mask="*"> 

<Iiteral>SEM_UNKNOWN</Iiteral> 

</bit> 
</bitfield> 
</typedef> 
</valueStr> 
<detaiILevel> 

<literal>l</literal> 
</detailLevel> 
</objAttribute> 

<objAttribute key="objIconSmaH"> 
<valueStr> 

<switcli fieIdName="seniState"> 
<case caseValue-"0"> 

<UtQral>sem.gif</]iteTal> 

</case> 

<case caseValue="*"> 

<literal>semempty.gif</literal> 

</case> 
</switch> 
</vaIueStr> 
</objAttribute> 
</objAttributes> 
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Fig. 4g 

<objGopher> 

<switch rieldNaine="cpu"> 

<case caseValue="*'*> 
<program> 

<! "Default Get object info for sem - taken from PPC860-> 
<I[CDATA[! <+0x30*<-H)x30@» 

<+0x28*$><+0x20*!><+0x8@>%nanieLookup%<+0x34@b><+0x35@b><+0x48@>]]> 

</program> 
<tape> 

<field fieldNamc="objId"/> 
<field fieldNaine="objTypeNumber7> 
<field fieldName="objName'7> 
<f5e]d fjeldName="objOwner"/> 
<field fieldName-"objChildListPtr7> 
<field fieIdName=*'semType"/> 
<field fieldName="seinOptions'V> 
<field fieldName="semState'7> 

</tanf»> 

■ — r ~ 

</case> 
</switch> 
</objGopher> 
<enuniByType> 

<switch fieIdNaine="cpu"> 

<case caseValue~"*"> 
<prograni> 

<l[CDATA[*+0x38** -0x18! <+0x30*<-H)x30@» 
<+0x28*$><+0x20* !x+0x8@> <+0x34@bx+0x35@bx+0x48@>+0xl 8@]]> 

</program> 
<tape> 

<field fieldName="objId"/> 
<field fieldNanie="objTypeNumber"/> 
<field fieldName="objName'V> 
<field fieldNan3e="objOwner"/> 
<field fieldNaine="objChildListPtr"/> 
<field fieldName-"semType"/> 
<rield rieldName="semOptions7> 
<field rieldName="seniState"/> 
<field rieldName="objSiblmgPtr"/> 

</tape> 
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Fig. 4h 



<program> 

<![CDATA[%objSiblingPtr% -0x18! <+0x30*<+Ox30@» 
<+0x28*S><+0x20*!><4^8@><-K)x34@b><4-0x35@b><+()x48@>K)xl8@]]> 

</program> 
<tape> 

<field fieldName="objId'V> 
<field fieldName="objTypeNumber"/> 
<field fieldNarae="objName*'/> 
<field fieldName-^"objOwner'V> 
<field fieldName="objChildListPtr7> 
<field fieldNaine="seznType"/> 
<field fieldNaine="semOptions"/> 
<field fieldNaine="seinState"/> 
<field fieldNaine-"objSiblmgPtr"/> 

</tape> 

</case> 
</switch> 
</enumByType> 
</objType> 
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Fig. 9a 



<?XTnl version="1.0" encoding"utf-8"?> 
<object name="binarySemaphore" 

icon='Tc:\wpwr\hostVesoiirce\bitmaps\WindView\events\semBCreate.brnp'*> 

<helpText> 

<synopsis> 

This is a short description of the object. 
</synopsis> 

<description> 

This is a much longer description of the object. 

This description can contain anything the user desires. 
<description> 

</helpText> 

<pubhcDataGet> 

<helpText> 

<synopsis>Get all pubUc data members</ synopsis> 
<description> A full description of the routine</description> 
</help Text> 

<requestBegin> 

<call nanie-"semRequestBegin"/> 

<retuni type='TJINT8*"/> 

<paiin type="SEM_ID"name='*seniId"/> 

</reqiiestBegin> 

<requestEnd> 

<callname="seniRequestEnd"/> 
<retum type= "STATUS"/> 
<parni type-'TJTNT8 *" name="pBuff 7> 
</requestEnd> 
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Fig. 9b 



<data> 

<dataltem type='TJINT"idref="pkLength''display=*'never'7> 
<dataItemtype='TJINT"idref="semId" 

text-"Handle"fomiat="0x08x"display="always" 

position="17> 

<dataltem type='TJINT"idre^"semClassId"display="never'V> 
<datalteni type- 'string" idref="name" 

text="Name" format="%s" display="always" 

position="0"/> 
<dataltem type="string" idref="owner" 

text-"Owner" format="%s" display="always" 

position="27> 
<dataltem type="int"diref='Value" 

text="State"format="translate"display="always" 

position="3" 

<translate key ="0" value="Empty" format="%s"/> 
<translate key="l" vaIue='Taken" format="%s"/> 
<translate key="*"value='TJnknown" format='Yos'V> 
</dataItem> 

</data> 

</pubicDataGet> 



</object> 



